Information on documentation relating to prior arts referred to in this description will first be disclosed.
Non-Patent Document 1: IEEE 802.1 Working Group, “Port-Based Network Access Control”, IEEE 802.1X Standard, June 2001.
Non-Patent Document 2: L. Blunk and J. Vollbrecht, “PPP Extensible Authentication Protocol (EAP)”, IETF RFC 2284, March 1998.
Non-Patent Document 3: Basavaraj Patil and A. Yegin, “Charter of Protocol for carrying Authentication for Network Access”, IETF PANA WG Charter, May 2002.
Non-Patent Document 4: C. Rigney, S. Willens, A. Rubens, and W. Simpson, “Remote Authentication Dial In User Service (RADIUS)”, IETF RFC 2865, June 2000.
Non-Patent Document 5: P. R. Calhoun, J. Arkko, E. Guttman, G. Zorn, and J. Loughney, “Diameter Base Protocol”, IETF Internet Draft: draft-ietf-aaa-diameter-12.txt, Work In Progress, July 2002.
Non-Patent Document 6: B. Aboba, “The Network Access Identifier”, IETF RFC 2486, January 1999.
The Internet today has evolved to a stage where numerous peripheral data communications networks are deployed around a system of fixed network nodes. Most of these peripheral networks are controlled by different service providers or organizations. As such, these networks utilize different methods to implement access control. In addition, the underlying network infrastructures are vastly different between these peripheral networks (e.g. wireless networks versus wired-line networks). Possible access control methods are limited by the underlying network infrastructure used. As a result, there exist a wide range of access control methods.
For instance, the IEEE (Institute of Electrical and Electronics Engineers) 802.1x standard defines a network access protocol for local area networks (Non-Patent Document 1). This standard defines an extension of the IETF (Internet Engineering Task Force) Extensible Authentication Protocol (EAP) (Non-Patent Document 2) for use in an IEEE 802 network, such as the IEEE 802.3 Ethernet or IEEE 802.11 Wireless network. Another example would be the ongoing effort of IETF in the Protocol for carrying Authentication for Network Access (PANA) Working Group (Non-Patent Document 3). Such network access protocols are usually deployed for local area networks, where the access control messages are limited to the local network.
In some situations, it might be necessary to transport the access control messages beyond the local are a network. For instance, the server that grants access may be located in a different local area network. Such situations occur when a single administrative domain consists of a number of local area networks. A central access server is usually used to control these local area networks since it is easier to manage and maintain access information if it is collected in one central area, rather than being distributed to various local area networks. Furthermore, such a scenario is becoming more and more common with the widespread deployment of mobile network infrastructure, where a mobile terminal may be roaming in a plurality of wireless networks in one remote area, and authenticated by a server in its home area.
For these situations, a protocol capable of traversing one or more packet switched networks is usually desired. Examples of such protocols are the widely deployed Remote Authentication Dial In User Service (RADIUS) protocol (Non-Patent Document 4), and the Diameter (DIAMETER) Protocol (Non-Patent Document 5) of the IETF, which is currently being defined. These protocols are typically used to provide a backbone infrastructure for authentication, authorization, and accounting servers to communicate among each other. Because these protocols are usually quite extensive, it is often considered too expensive (in both a computation and memory sense) to deploy in end terminals.
A typical deployment will be for terminals to use a local access protocol, such as IEEE 802.1x, to perform access requests to a local intermediary. This intermediary then contacts a remote global server using RADIUS or DIAMETER that performs the actual authorization and authentication. Such an arrangement is most commonly seen in, but not limited to, a wireless network environment where the wireless mobile node uses EAP to request access, and the wireless access point uses RADIUS or DIAMETER to verify the wireless user with a server on the wired network.
In a network access environment where the local nodes uses one or more local access protocols such as PANA, IEEE 802.1x, or other EAP-based protocols, and the global authentication server uses another global access protocol such as DIAMETER or RADIUS, there is no efficient way of maintaining the sessions between the two protocols at the intermediary. In addition, implementation of an intermediary is often tightly coupled to the access protocols, so that the change of an access protocol would require substantial effort to modify the intermediary.
Of the studied prior arts, only DIAMETER (Non-Patent Document 5) specifies the possibility of an intermediary capable of linking two different protocols, known as a “translation agent”. However, specification of such an agent is absent. For 802.1x (Non-Patent Document 1), an intermediate “authenticator system” is defined. This, however, is confined to an intermediary using the same 802.1× protocol when communicating with both end-points of an authentication session. The charter of the PANA working group (Non-Patent Document 3) specifically identifies the PANA protocol to be used within one hop, i.e. there can be no intermediary using a PANA protocol to communicate with both the local node and the global server. The intermediary, in such cases, will have to use a different protocol to relay an authentication session to the global authentication server. Unfortunately, the architecture and operation of such an intermediary is not defined.
Furthermore, since many deployments of such an intermediary are in a wireless environment, it is highly possible to envisage an intermediary which is itself mobile, such as a wireless access point in a train or aircraft. With such settings, there is a significant possibility that the connection between the intermediate node and the global server may be momentarily down. This is especially true when there is a high frequency of handovers between base stations. Most implementations of access control are not optimized for such a scenario. Often, access requests of local nodes are rejected or put on hold when the intermediate node cannot locate the global server. This is counter-productive if the local nodes just need to communicate with each other.